29.2 KB · ⇊ 9 parts · ⤓ Micron 29.2 KB · ⤓ HTML 44.4 KB

top

Nel campo delle mwbareti di telecomunicazioni, il termine mwbqqualità del servizio o più semplicemente mwbgQoS (dall'mwbwinglese mwcaQuality of Service) è utilizzato per indicare i parametri usati per caratterizzare la qualità del mwcqservizio offerto dalla mwcgrete (ad esempio perdita di mwcwpacchetti, mwdaritardo), o gli strumenti o tecniche per ottenere una qualità di servizio desiderata.

La qualità del servizio è normalmente correlata negativamente con il mwdgtraffico offerto alla rete, e positivamente con le risorse impegnate per realizzare e gestire la rete.

Il traffico offerto alla rete e l'intervento di malfunzionamenti sono usualmente modellati come mweaprocessi stocastici: di conseguenza, i parametri usati per caratterizzare la qualità del servizio sono comunemente mweqvariabili casuali.

Quando un mwewcontratto di servizio prevede dei parametri di qualità del servizio, con relative penali nel caso questi parametri non vengano rispettati, si parla di SLA o mwfaService level agreement (accordo sul livello del servizio).

• Descrizione

• Telefonia

• Reti a pacchetto

• Applicazioni che richiedono QoS

• Meccanismi di QoS in Internet

• Overprovisioning

• Priorità

• Discussione

• Problemi del QoS con alcune tecnologie

• Note

• Bibliografia

• Voci correlate

• Altri progetti

• Collegamenti esterni

Nel campo della mwgqtelefonia, e in generale della mwggcommutazione di circuito la qualità del servizio prevede parametri come:

• mwhqdisponibilità del servizio;

• livello di mwhwrumore sul circuito;

• livello sonoro;

• mwigprobabilità di trovare una linea libera per iniziare una comunicazione;

• probabilità di interruzione indesiderata di una comunicazione;

• durata media e massima dei disservizi.

In una mwjwrete a pacchetto, un pacchetto ricevuto da un commutatore può trovare la porta su cui dovrebbe essere trasmesso impegnata da un altro pacchetto in trasmissione. In questo caso, viene memorizzato in una coda di un mwkabuffer, e subisce per questo un ritardo di accodamento. Nel caso la coda sia piena, il pacchetto viene scartato o perso.

I parametri tipicamente considerati per una rete a pacchetto sono:

• consegna fuori ordine o mwlaout-of-order – su alcune reti, è possibile che una sequenza di pacchetti inviati da un nodo ad un altro venga consegnata in un ordine diverso da quello originale. Questo accade tipicamente perché i pacchetti vengono instradati su percorsi diversi per via della mwlqcommutazione di pacchetto. Questo problema rende necessario che i protocolli di trasporto riordinino i pacchetti fuori ordine una volta che sono giunti a destinazione e comporta ulteriori ritardi nella ricostruzione del flusso di dati a livello applicativo. Dal punto di vista quantitativo viene considerata la probabilità che un pacchetto arrivi fuori ordine.

• errore di trasmissione: un pacchetto può essere consegnato a destinazione, ma non essere identico a quello inviato. Molte reti riconoscono la gran parte degli errori di trasmissione, e alcune sono anche in grado di correggere tali errori. Dal punto di vista quantitativo si considera la percentuale di pacchetti errati. Normalmente i protocolli di trasporto riconoscono un pacchetto errato e ne richiedono la ritrasmissione come se questo fosse stato perso, ma è anche possibile che l'errore raggiunga l'applicazione finale.

• ritardo (mwmadelay) subìto da un pacchetto dalla sua immissione nella rete alla consegna al destinatario. Vengono considerate caratteristiche come il ritardo medio ("i pacchetti in media impiegano 10 ms ad attraversare la rete"), e i suoi mwmqpercentili ("il 99% dei pacchetti viene consegnato entro 20 ms"). Viene anche considerato il mwmgjitter, ovvero la variazione del ritardo tra pacchetti inviati in sequenza da un nodo ad un altro.

• perdita di pacchetti o mwnadropped packets (mwnqpacket loss): viene considerata la percentuale di pacchetti che la rete nel suo complesso non riesce a consegnare a destinazione. La perdita di un pacchetto viene gestita in modi diversi dai protocolli di trasporto, anche se questo esula dalla definizione della qualità del servizio della rete: in un protocollo senza riscontro, si avrebbe la mancata trasmissione dell'informazione, in un protocollo con riscontro come mwngTCP, il ricevente, dopo aver atteso un tempo ragionevole, deve chiedere che l'informazione venga ritrasmessa, causando anche gravi ritardi (mwnwdelay) nella trasmissione complessiva.

• mwoqthroughput: ai precedenti parametri si aggiunge generalmente la mwogbanda il cui valore massimo consentito dipende dal contratto stipulato dall'utente con il mwowfornitore del servizio.

Per applicazioni o servizi mwpqnon real-time come il mwpgfile transfer o il mwpwvideo sharing, alcuni di questi parametri (ad eccezione del ritardo e del throughput) vengono soddisfatti dal mwqaprotocollo di rete mwqqTCP che si occupa proprio di richiesta di riordino e recupero di errore sui pacchetti pervenuti e di ritrasmissione dei pacchetti persi ovvero non pervenuti a prezzo di un certo tempo di elaborazione. Il ritardo e la sua variabilità per tali applicazioni non è considerato un parametro critico in quanto tollerato dall'utente come tempo necessario a soddisfare la sua richiesta di acquisizione dei dati. Se il tempo di trasmissione è eccessivo l'utente tipicamente tende a richiedere un mwqgthroughput maggiore che però è soddisfacibile dal fornitore solo attraverso una maggiore mwqwbanda.

Per applicazioni mwrqreal-time, come la fonia su IP (mwrgVOIP) e lo mwrwstreaming audio-video in diretta diventano invece sensibili i parametri di ritardo, variabilità di ritardo e perdita di pacchetti che implicano rispettivamente tempi di mwsalatenza troppo elevati, jitter che dà luogo a consegna fuori sequenza e conseguente necessità di mwsqreordering con ritardo aggiuntivo di elaborazione, ed infine richieste di ritrasmissione da parte di TCP con ulteriore ritardo aggiuntivo. In tali applicazioni quindi si preferisce evitare l'uso del protocollo TCP in favore dell'altro protocollo di trasporto mwsgUDP che non fa controllo di trasmissione ovvero non esplica le funzionalità di cui sopra, al prezzo di qualche perdita di dati.

In aggiunta a ciò spesso si rende necessaria una garanzia maggiore sui cosiddetti parametri di qualità del servizio (QoS) nel caso di comunicazioni mwtareal-time come la mwtqfonia e la diffusione di contenuti mwtgmultimediali mwtwaudio-mwuavideo real-time in situazioni di mwuqcongestione sui mwugnodi interni di mwuwcommutazione.

Il modello di QoS originale di Internet, ovvero nessuna QoS, è adatto ad applicazioni mwvgelastiche, che possono funzionare anche su reti con prestazioni molto degradate, e viceversa usare tutta la banda a disposizione se questa è abbondante.

Altri tipi di servizio sono invece chiamati mwwainelastici, ovvero richiedono un certo livello di banda per funzionare – se ne ottengono di più non la sfruttano e se ne ottengono di meno non funzionano affatto. Sono queste applicazioni che rendono necessaria l'adozione di misure per garantire una certa QoS.

Applicazioni che richiedono una QoS sono ad esempio le seguenti:

• mwxamultimedia streaming: può richiedere un mwxqthroughput garantito;

• telefonia mwxwVoIP può richiedere vincoli molto stretti sul ritardo e sulla variabilità del ritardo (mwyajitter);

• emulazione di collegamenti dedicati richiede sia un mwygthroughput garantito che un ritardo massimo limitato;

• un'applicazione critica per la sicurezza, come la chirurgia remota, può richiedere un livello garantito di disponibilità, ciò è chiamato anche mwzahard QoS.

In contesti lavorativi, può accadere che vengano definiti dei requisiti di QoS anche per applicazioni che non sono intrinsecamente elastiche, per garantire livelli adeguati di produttività. Ad esempio, "il terminale dell'agenzia di viaggi deve riuscire a completare la transazione entro 10 s nel 98% dei casi". Spesso però un requisito di questo tipo richiede di intervenire sia sulla rete che sul mwzgsistema informativo che eroga il servizio (ad esempio, allestire un numero adeguato di server).

Quando è stata creata mwaqInternet, non era stata percepita la necessità di QoS per le applicazioni. Infatti l'intera Internet segue la filosofia del mwagmwawbest effort, cioè il sistema garantisce di fare tutto il possibile per portare a termine un'operazione, ma non garantisce affatto che l'operazione verrà compiuta, né in che modo. Anche se il mwbaprotocollo IP prevede 4 bit per il tipo di servizio (mwbqtype of service) e 3 per la mwbgprecedenza di ciascun pacchetto, questi bit sono largamente inutilizzati. Al crescere del numero e tipologie di servizi e del mwbwtraffico offerto rispetto alle capacità della rete il problema della qualità del servizio ha cominciato a divenire importante e sempre più considerato.

Ci sono fondamentalmente due modi per fornire garanzie sulla Qualità del servizio.

Il primo metodo, detto overprovisioning (mwcwmwdasovradimensionamento), consiste nel fornire risorse di rete (di trasmissione, memorizzazione ed elaborazione) in abbondanza, abbastanza da soddisfare la domanda di mwdqpicco attesa, con un sostanziale margine di sicurezza. Una soluzione semplice, ma alcuni credono che in pratica sia troppo costosa e non sia applicabile se la domanda di picco cresce più velocemente di quando predetto: disporre nuove risorse richiede infatti sempre tempo.

L'alternativa è amministrare la banda disponibile, facendo in modo che i pacchetti che giungono ad un mweanodo di rete (mweqrouter) subiscano un trattamento differenziato ovvero quelli a cui deve essere garantita una certa QoS ricevano in particolar modo un trattamento privilegiato. Per ottenere questo, bisogna risolvere due problemi:

• Identificare i pacchetti che devono ricevere un trattamento privilegiato (mwfaclassificazione o mwfqdiscriminazione del traffico).

• Applicare a questi pacchetti identificati una disciplina di coda (mwfwqueue discipline) che garantisca le prestazioni necessarie da applicare poi sulle mwgaporte o mwgqinterfacce di uscita dei router.

I metodi strutturati per identificare il traffico da privilegiare sono:

• mwhgIntegrated services, basato sulle prenotazioni: prima di iniziare una sessione che ha dei requisiti di QoS, l'applicazione deve "chiedere" alla rete se questa può garantire le prestazioni necessarie (mwhwadmission control): la rete valuta se dispone delle risorse adeguate e in caso positivo accetta la prenotazione concedendo il servizio richiesto.

• mwiqDifferentiated services, prevede che gli utenti della rete stipulino a priori un contratto che definisca la quantità massima di traffico "privilegiato" che essi possono generare e marchino tale traffico utilizzando il campo mwigType of Service (mwiwTOS) dell'mwjaheader IP. In questo caso quindi le prenotazioni sono rigidamente "statiche".

Soprattutto nelle reti di piccole dimensioni, è possibile utilizzare metodi più semplici, che prevedono di identificare manualmente sui router il traffico a cui dare priorità, tipicamente usando delle mwjgliste di controllo degli accessi (ACL).

In un router che non applichi politiche di qualità del servizio, i pacchetti vengono trasmessi sulle porte in uscita nell'ordine in cui sono arrivati. Una disciplina di coda, o mwkqscheduling dei pacchetti, consiste essenzialmente nel gestire per ciascuna porta diverse code in uscita, in cui i pacchetti vengono classificati. La disciplina di coda stabilisce in quale ordine verranno prelevati i pacchetti dalle varie code.

Esempi di disciplina di coda:

• priorità stretta: le code sono ordinate per priorità. Ogni volta che si deve trasmettere un pacchetto, lo si preleva dalla coda a priorità più alta che ha un pacchetto pronto. In questo modo, una applicazione di priorità superiore può monopolizzare l'intera banda disponibile, a danno di quelle di priorità inferiore (starving).

• Weighted round robin: viene prelevato a turno un pacchetto da ciascuna coda. In questo modo, si garantisce che tutte le classi di applicazioni potranno trasmettere. Il "weighted" significa che a ciascuna coda può essere attribuito un peso, ovvero una frazione della banda disponibile, e i pacchetti vengono prelevati in modo da garantire questa banda disponibile. Se una classe di traffico in un certo momento non utilizza la banda allocata, questa è utilizzabile dalle altre (bandwidth borrowing).

• Discipline di coda più avanzate, come Hierarchical Packet Fair Queueing (H-PFQ) e Hierarchical Fair Service Curve (H-FSC), permettono di esprimere per ciascuna coda sia un requisito sulla banda che uno sul ritardo. Al momento, sono disponibili solo su router software, basati su mwmaBSD o mwmqlinux. Si veda a proposito mwmgHierarchical Fair Service Curve Scheduler..

Altri strumenti utilizzati per amministrare la banda disponibile:

• mwngRED (mwnwRandom Early Detection o Rilevazione casuale anticipata): quando si approssima la mwoacongestione, la rete scarta arbitrariamente una piccola percentuale del traffico. Questo viene interpretato da mwoqTCP come una indicazione di congestione, abbassando la quantità di traffico inviata. Un caso particolare di questa tecnica chiamato WRED (mwogWeighted Random Early Detection) permette di distinguere il flusso di traffico dal quale iniziare a scartare i pacchetti in presenza di congestione. Con il WRED è possibile definire delle soglie di utilizzo del link che, una volta raggiunte provocano lo scarto di pacchetti appartenenti a specifiche classi di traffico. Così al raggiungimento della prima soglia verranno scartati solo pacchetti di flussi poco importanti, mentre al raggiungimento di soglie di utilizzo via via più alte verranno scartati anche pacchetti appartenenti a flussi di traffico più importanti. Il "weighted" significa che la classe di traffico che sperimenterà il maggior numero di pacchetti droppati sarà quella associata alla soglia più bassa. La definizione delle soglie di utilizzo e dei diversi flussi di traffico è fatta su base configurazione.

• rate limiting: una classe di traffico può essere limitata in modo che non utilizzi più di una certa banda.

Il mercato non ha ancora favorito la nascita di servizi QoS end-to-end, ovvero in grado di garantire vincoli sulla QoS di un flusso di dati scambiati tra utenti remoti. Alcuni credono che una rete mwpgstupida cioè sovradimensionata, che offra cioè sufficiente banda per la maggior parte delle applicazioni e per la maggior parte del tempo, sia già economicamente la migliore soluzione possibile, mostrando poco interesse a supportare applicazioni non-standard capaci di QoS.

La rete Internet ha già accordi complessi tra i provider e sembra che ci sia poco entusiasmo nel supportare il QoS attraverso connessioni che interessano reti appartenenti a provider diversi, o sugli accordi circa le politiche che dovrebbero essere sostenute al fine di poterle supportare.

Gli scettici sul QoS indicano che se si scartano troppi pacchetti su una connessione elastica a basso QoS, si è già pericolosamente vicini al punto di una congestione per le applicazioni inelastiche ad elevato QoS, non essendoci più modo di scartare ulteriori pacchetti senza violare i contratti sul traffico.

È inoltre importante sottolineare come la gestione della QoS nelle reti di accesso wireless di tipo mwqgLTE e mwqwWiMAX sia un tema di primaria rilevanza da affrontare per la diffusione di tali tecnologie. Infatti, gli enti preposti al rilascio delle specifiche di LTE e WiMAX hanno già incorporato i meccanismi standard necessari a gestire la QoS offerta ai terminali.

''to do: mention [[Paris Metro pricing]] as a minimal QoS policy''

In termini generali, come evidenzia Kotler, poiché le aziende trovano più difficile differenziare i loro prodotti fisici, si rivolgono alla differenziazione del servizio, sia che ciò significhi consegne puntuali, risposte migliori e più rapide alle richieste o risoluzione più rapida dei reclami. I migliori fornitori di servizi conoscono bene questi vantaggi e sanno anche come creare esperienze memorabili per i clienti.cite-ref-1[1]

Le seguenti proprietà possono essere usate solo sulle porte finali, ma non sui mwtaserver, mwtqbackbone o altre porte, che mediano molti flussi concorrenti.

• mwuahalf duplex - collisioni sul collegamento possono far variare i ritardi (mwuqmwugjitter), perché i pacchetti sono ritardati da ogni collisione con un tempo di backoff.

• Porte con buffer a coda IEEE 802.3x (mwvacontrollo di flusso).

Il controllo di flusso dell'IEEE 802.3x non è un reale controllo di flusso, ma piuttosto un controllo di coda. Un esempio di problemi dell'IEEE 802.3x sono i blocchi mwvghead of Line. Molti degli switch odierni usano l'IEEE 802.3x di default - anche sulla porta di uplink/backbone.

Citazione da: mwwaNetwork World, 09/13/99, 'Flow control feedback'. URL consultato il 3 aprile 2018 (archiviato dall'url originale il 10 marzo 2005).: "...Hewlett-Packard points out that quality of service is a better way to handle potential congestion, and Cabletron and Nortel note that QoS features can't operate properly if a switch sends [IEEE 802.3x] pause frames...."

Questa citazione suggerisce che QoS e IEEE 802.3x sono tra loro incompatibili.

cite-note-11. ↑ Philip Kotler and Kevin Lane Keller (2016). Marketing Management, 15th edition, Pearson Education, Harlow.

• M. Menth, R. Martin, and J. Charzinski “Capacity Overprovisioning for Networks with resilience Requirements". In Proc. of ACM Sigcomm 2006.

• mwzgNeutralità della rete

• mw0aQualità dell'esperienza

• mw0gMPLS

Altri progetti

• Wikizionario

• Wikimedia Commons

• Wikizionario contiene il lemma di dizionario «QoS»

• Wikimedia Commons contiene immagini o altri file sulla qualità di servizio

• citereffoldoc(EN) Denis Howe, quality of service, in Free On-line Dictionary of Computing. Disponibile con licenza mw1wGFDL

• mw2qIEEE 802.1 P,Q - QoS on the MAC level, 24.4.1999, Niclas Ek, su tml.hut.fi. URL consultato il 19 giugno 2005 (archiviato dall'url originale il 31 maggio 2005).

• mw2wIEEE 802.1 LAN/MAN Bridging & Management, su standards.ieee.org.

• mw3q"Good old days" IP QoS: Type of Service in the Internet Protocol Suite, su sunsite.dk. URL consultato il 19 giugno 2005 (archiviato dall'url originale il 2 dicembre 2001).

• mw3wOn the Effects of the IEEE 802.3x Flow Control in Full-Duplex Ethernet LANs, Oliver Feuser, Andre Wenzel, University of Bonn, su computer.org. URL consultato il 19 giugno 2005 (archiviato dall'url originale il 12 ottobre 2004).

• mw4qsslug.dk: Hyggemøde tirsdag den 11. juni 2002: Båndbreddebegrænsning, su sslug.dk. URL consultato il 19 giugno 2005 (archiviato dall'url originale il 13 marzo 2005).

• mw4wsslug.dk: Hyggemøde tirsdag den 11. juni 2002: Båndbreddebegrænsning. Eksempler (TXT), su sslug.dk. URL consultato il 19 giugno 2005 (archiviato dall'url originale il 18 febbraio 2005).

• mw5qLinux Advanced Routing & Traffic Control, su lartc.org. URL consultato il 19 giugno 2005 (archiviato dall'url originale il 15 ottobre 2011).

• mw5wLinux Advanced Routing & Traffic Control, HowTo, su lartc.org. URL consultato il 17 novembre 2022 (archiviato dall'url originale l'11 ottobre 2007).

• mw6qlartc.org: The Wonder Shaper, su lartc.org. URL consultato il 19 giugno 2005 (archiviato dall'url originale il 31 maggio 2005).

• mw6wPacketeer PacketShaper 2500: Traffic Control on Autopilot, September 4, 2000, By David Newman, su networkcomputing.com. URL consultato il giugno 19, 2005 (archiviato dall'url originale il 21 aprile 2003).

• mw7qPacketeer PacketShaper, su packeteer.com. URL consultato il 19 giugno 2005 (archiviato dall'url originale il 19 ottobre 2005).

• mw7wTraffic Shaping application for Windows (has free version), su inetshaper.com.

• mw8qALTQ: Alternate Queueing for BSD UNIX (archiviato dall'url originale il 27 settembre 2007).